A service proxy is often used as a data bridge in applications that adhere to the IEEE 1394.1 Serial Bus Standard. A service proxy preserves legacy interoperability for devices such as audio/video (AV) devices that aren't bridge aware. A local bridge acting as a service proxy serves as an AV target for a legacy controller and then sends AV commands to another bridge acting as service proxy on a remote bus. The service proxy on the remote bus, posing as a local AV controller, in turn forwards the AV commands to the real AV target. After connecting the legacy controller and target in this fashion with service proxies, transmission of isochronous stream data may begin with isochronous data from the source bus being repeated across intervening buses to the final sink bus.
The repeating of isochronous data from one bus to another (through possible intervening buses) poses some challenges. Specifically, the time base for any given bus can be different from any other bus by as much as +/−100 parts per million (ppm). Such variations in time bases may cause overruns and underruns when data is passed between buses having different time bases. A method is required to synchronize the various isochronous elements such as a sink bus, source bus, or intermmediate buses, so that the isochronous data path faithfully recreates the source data rate without overruns or underruns.
The IEEE1394.1 standard defines a solution to this data rate matching problem that forces synchronization of all buses to a common BASE_RATE. According to the IEEE1394.1 solution, a bridge issues commands on an attached bus to speed up or slow down the cycle master for a particular bus. Doing so in a recursive or distributed fashion allows all buses to be synchronized to a single clock reference contained in the 1394.1 net cycle master. Having established a single clock reference, isochronous packets captured on one bus, such as the source bus, can be faithfully repeated cycle by cycle on all intervening buses and on the final sink bus without risking overflow or underflow.
However, several shortcomings are evident in the IEEE 1394.1 solution. The IEEE1394.1 solution requires a cycle master on each bus to be capable of adjusting its time base on command. Existing cycle master devices do not have this capability. Consequently, bridge devices often must serve as the root on each local bus to provide the cycle adjustment capability. Forcing the bridge device to be root may not be optimal, however, for certain circumstances and performance considerations. For example, it is preferred to have a B device be root over a legacy device.
Another challenge is that network-wide propagation of the master time reference requires bridge devices to be capable of forwarding the time reference from one portal to another portal. While this may be a simple task if both portals are located in the same enclosure, silicon die, etc., it becomes more problematic in the case of a distributed bridge in which the portals are physically separated, such as by a wireless connection.